txt: perform per-domain (and frametable and xenheap) MAC on entry into
authorKeir Fraser <keir.fraser@citrix.com>
Tue, 3 Mar 2009 12:48:16 +0000 (12:48 +0000)
committerKeir Fraser <keir.fraser@citrix.com>
Tue, 3 Mar 2009 12:48:16 +0000 (12:48 +0000)
commit6deab1ae316b5f7da431d8add34c676dfca9c4f9
tree83d88eac3224e24acc9a6c4e8be971ed681810d3
parent8aaf870611964a738533c7300e0858e293f5f23a
txt: perform per-domain (and frametable and xenheap) MAC on entry into
S3 and verification on resume.

The MAC algorithm is called VMAC and was developed by Ted Krovetz and
Wei Dai (more details are in the files).  It is based on a universal hash
function.  The universal hash is passed through a pseudo-random function,
implemented using AES.  More details can be found at
http://fastcrypto.org/vmac/. =
 The AES code comes from the OpenBSD implementation (which is derived
 from the implementation referenced in VMAC site).

As Xen does not have a good source of entropy to generate its own key
(for the keyed hash), it uses the key that tboot passes in.

Although the code attempts to MAC all of a domain's pages (code/data,
VT-d tables) based on its s3_integrity flag, some of a domain's memory may
always be MAC'ed, e.g. shadow page tables.  Only xenheap pages that are in
use are MAC'ed.  We believe that the memory MAC'ed by the Xen code and the
ranges passed to tboot to MAC cover all of the memory whose integrity needs
to be protected on S3.  Any suggestions or ranges that we missed are
welcome.

Signed-off-by: Shane Wang <shane.wang@intel.com>
Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
xen/Rules.mk
xen/arch/x86/acpi/power.c
xen/arch/x86/tboot.c
xen/crypto/Makefile [new file with mode: 0644]
xen/crypto/rijndael.c [new file with mode: 0644]
xen/crypto/vmac.c [new file with mode: 0644]
xen/include/asm-x86/tboot.h
xen/include/crypto/rijndael.h [new file with mode: 0644]
xen/include/crypto/vmac.h [new file with mode: 0644]